As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
In many information handling systems, a basic input/output system (BIOS), for example a Unified Extensible Firmware Interface (UEFI), is capable of operating in a pre-boot mode in which the BIOS executes certain instructions prior to loading and execution of an operating system. In an information handling system employing UEFI, a storage resource of the information handling system may include an EFI System Partition (ESP). When an information handling system is powered up and booted, UEFI firmware may load files stored on the ESP to start installed operating systems and various utilities.
Presently, across the industry there are numerous different mechanisms to access an ESP which may vary based on operating system, file system type, or other parameters, and no industry standard to address the access mechanism to an ESP. For example, in Linux systems, gummiboot operates on the ESP only, meaning configuration file fragments, kernels, and other EFI images need to reside on the ESP. Linux kernels must accordingly be built with an appropriate stub to be able to be directly executed as an EFI image. gummiboot may read simple and entirely generic boot loader boot loader configuration files, with one file per boot loader entry to select from, and with all files residing in the ESP. On the other hand, on Apple-Intel architecture Macintosh systems, the ESP may initially be blank and may not be used for booting. However, the ESP may be used as a staging area for firmware updates. As another example, Microsoft recommends that when partitioning a storage resource, the ESP be the first partition on the storage resource, even though this is not a requirement of the UEFI specification itself. On later versions of Microsoft operating systems, access to ESP may be obtained by running a command to mount volumes.
In addition, multiple vulnerabilities may exist in allowing operating systems to access an ESP directly. If an operating system is vulnerable, system recovery embedded in operating system loaders or in a recovery partition may not be accessible once the ESP is corrupted as the ESP is the main partition to access system boot and system-dependent files. In spite of systems enabled with SecureBoot or similar features, SecureBoot is not guaranteed to run in operating system space across all operating systems, and once handover from UEFI to operating system loaded is complete, UEFI SecureBoot functionality is complete. Thus, if the operating system is vulnerable, malicious code may take over an entire system by injecting malware into the ESP, as the ESP is a direct access mechanism from the operating system.